attack NFC platforms using quite basic components. So what is NFC? Mainly it's to
do with opening doors or paying for things or accessing the underground
train system and yeah it's basically one card being spoken to by a reader that
illuminates it with a field using induction and communicates with it. Why
would we attack NFC? Well as I said before it's used in payment systems, door
access control systems and metro lines and it can be found anywhere and it's
a type of protocol that is quite insecure with most of the
security relying on very weak encryption or the fact that there is a very very
low range for the tags and the readers. So as I said before we're going to talk
about the protocols involved and how you build tools to work with them and
from there we're going to talk about the main standard which is
used which is ISO 14443. Now this is the 13.56 megahertz protocol which is for
my fair classic cards and ultralight cards which are generally used for hotel
room keys or door controls. It defines characteristics as ISO 14443A which is
the most common and 4443B which is slightly less used. From there we're
going to build a tool that will analyze and emulate a my fair classic tag using
these protocols.
So low-level communication wise tags are powered by an electromagnetic
inductor from the reader which basically powers it through the inductors so that
the card can communicate back and forth using that power to communicate via
drawing load from the reader. The reader uses a modified Miller encoding
this is a kind of encoding which basically has a large amount of space
between bits so that there's not too much power loss or glitching due to the
communication being involved and as and responses are sent by Manchester
coding which is a radio encoding scheme which is basically for keeping track of
data quite simply and with a high level of timing issues. So modified Miller as
I said before it's basically disabling the field at certain intervals making
sure that the tag has enough power to still run but to also receive data so
it's defined as a 0.0 bit being a low transition followed by high for
the rest of the transmission.
bit after one being high for the entire transmission and a one bit just being
high for the first half of the transmission a small dip and then back
up again and this is completely designed so that there is never a really small
gap between power losses and that the communication works well. Manchester
coding is performed by modifying the phase of a signal using a sub carrier
this is done by basically drawing loads from the reader so that you can
analyze that to see what the tag is saying and this is done so that there
doesn't need to be some kind of proper two-way communication. So how basic
enumeration works is the reader always starts off the transaction and the tag
always responds so it usually starts off with the reader giving a request or wake
up command which the tag then responds with a response defining the basics of
what the tag does. The reader then tries to select a tag by requesting any tags
in the field to send their unique identifying number now this can be four
bytes, three bytes, three bytes, three bytes, three bytes, three bytes, three bytes, three bytes.
seven bytes or nine bytes and then the reader can then select using that ID and
the end of that transaction is the tag sending the SAK response which is the
very specific definition of what kind of tag it is. From there the reader can then
try and authenticate or communicate with the tag in the way that it's meant to.
There is an extra section which is called anti collision this is performed when
there's more than one tag on a reader at the same time and they haven't yet
enumerated properly.
It involves the requesting responses based on partial UIDs so when the reader
sends a request for all the UIDs in the field it will often get garbled
communication back because the communication being sent is from two
tags at the same time so what it does is it tries to differentiate between the
two using small amounts of the unique identifiers that are used. Increasing
number of bits as it goes along will mean it eventually finds a set of unique identifier
bits that do not match on both tags and then it can select that unique identifier and
then go through to the next one.
So we're going to talk about a few different kinds of tags there are so the first one is
my fraught flight which is the most simple there is. So that uses an authentication key
which is sent to the tag in the plane. Usually there are other ways that it can be done
but this is the most basic way. If the key is accurate the reader has authenticated and
then send communication which isn't encrypted and all the communication can be performed.
If it's wrong then usually the tag will log the failed communication and lock after a
while.
So that tag can never be used again. It can also be set up to use no
authentication which is quite insecure. It has support for a few
different other authentication techniques especially in newer versions
such as my fraught flight C but usually these aren't used and more complex and
secure methods are used at that point. There's my fair classic which is
probably the most common you'll see anywhere in the world so this is used
everywhere and is one of the most insecure protocols there are and yet
it's still used everywhere.
It utilizes the crypto one algorithm which is known to be broken in a huge number of
ways. Basically the reader requests authentication for a sector of the tag. The tag responds with
a unique four byte value. The reader responds with a brand new value followed by a value
generated by the original random value sent by the tag which is then encrypted and the
tag responds with an encrypted number generated from that value. All further communication
is then encrypted using this algorithm from that authentication.
Each sector of the tag can have two keys and they can be completely unique to
that section of the tag. Then finally there's my fair death fire which is
interesting because it is not broken yet in any reasonable manner so it's
based on different application IDs and it can authenticate based on DES, triple
DES and AES depending on how it's set up. Multiple keys can be used for
authentication and it can be authenticated. The authentication works similarly to my
fair classic. The reason it's not been broken in the same way is due to the fact that my
fair classic's weaknesses lie in the encryption used and as my fair death fire is using slightly
more complex encryption it's more secure against these attacks.
So first we're going to talk about creating analysis tools for hacking NFC. So usually
when you think of these things you think of like the proxmark or maybe more complex tools
like the ESRP and I decided to try and make tools out of the most basic components I could
find. So anything that I could get as raw components or as a very small tool.
So here's a list of some of the existing tools. So you have the proxmark and the
chameleon mini which are the most well known and the most commonly used for
actual engagements and tests. The proxmark 3 being able to be a reader, a
tag or just passively sniff the communication. There is hydro NFC, simple
NFC and emu tag which are more hobbyist level projects and are very interesting
in their own way because they can perform communication with small tools
especially the same as some of the tools I've created today are. So firstly how do
you detect an NFC field?
Well you can detect it with just an LED and a coil of wire. If you put that circuit as
small as it is into an NFC field that LED will light up and tell you when communication
is occurring. It's very useful for detecting whether the field is active but apart from
that it's just interesting to see how simply it can work.
First thing I wanted to do though was create a passive sniffing tool so basically so I
could see the communication between a reader and a tag and view how the communication goes
on and see where the attacks can lie. So I used an RCL SDR which is a
basic and most cheap SDR tool you can buy. It can tune between 25 MHz and 1700 MHz, it's
got quite a strong sample rate that can be configured quite well and there's a huge
number of libraries that can work with it. There are a few problems for what we were
doing though as it couldn't tune all the way down to 13.56 MHz without some hardware
modifications and the low sample rates used by the communication between the tag and
the reader it was just too high for so I'd have to find a way around that. It's also
bundled with some weak hardware including the weak antenna and it's also bundled with
the weak antenna and it's not really built for a specific purpose which is the main
problem with software defined radios. So I managed to get past most of these limitations
by using little tricks with no hardware modifications necessary. So firstly in order to read the
communication from a reader I tuned up to 27.12 MHz which is the harmonic frequency
of 13.56 MHz. Due to the fact that there's a huge amount of raw power going through a
device to communicate with a tag it's possible to pick up all the harmonic frequencies and
all the noise coming and use that to get the signal and the definition as it's going through.
I could synchronise with the sample rate twice what it needs to be so I set it to 1.695
MHz which is double the 847.5 kHz required for communication. Antenna modifications weren't
required as I took that first circuit, the LED in the coil and put it around the antenna
that came with it.
Due to the fact that when a reader detects any tags in the field it ramps up the power
being used I managed to pick up the signal from that. As there was a constant signal
I could also use automatic gain control which meant it could be very easily analysed as
things were going on. I managed to get real time analysis of communication from a reader
to a tag but not the other way around. Due to the fact that I was using a harmonic frequency
it wasn't possible to get it the other way around.
So here's a dump of the output as it came from the reader. So first we start with a
wake up command.
It's basically saying any tags that haven't been spoken to yet please talk to me. A selection
because it already knew the tag that was in place and a halt command saying it doesn't
want to communicate anymore. And then another request in order to see if there are any other
tags on the reader and a wake up to speak to the tag it had already spoken to again.
From here I wanted to build a Myfair Classic tag from scratch in a way where I could do
completely raw communication with it and modify any parts of the protocol I needed to. So
I wanted to do it without any abstract hardware whatsoever.
No NFC chipsets, I just wanted to use a microcontroller and any hardware I could make. I wanted to
use minimal components and cheap components so that I could make it really reproducible
and also because if I take that concept and make it really simple I can then add complex
features to it later. It would require me to implement the crypto one authentication
in a way which is usable and add complexity to the project when it was going on. By fully
implementing this protocol though I'd be able to find weaknesses in it and also create tools
to attack them.
Inductive coupling, exactly the same as the LED in the coil or anything else. This signal
would need to be demodulated by amplitude. This would not be possible on the microcontroller
so it would need to be done in hardware. And I would need a microcontroller which was
fast enough and powerful enough to run at 13.56 megahertz accurately. This would also
require complex encryption calculations which would need to be done sufficiently quickly
and it would need enough memory to do them as well.
So let's start with the circuit. So I started with an LC circuit. This is just an inductor
and a capacitor together.
Which is used to tune to the reader's inductive coupling. I could just test with a big coil
of wire and multiple different capacitors until in a logic analyzer I got a frequency
that matched digitally. Due to the amount of power being put through it's possible just
to check with a logic analyzer rather than a scope or anything more complex.
I then added an envelope detector which can be made from a diode, resistor and capacitor.
Now this is used commonly for decoding AM radio signals.
Especially when they're using binary and amplitude shift key. And it literally works
by rectifying the signal and then smoothing it until you get the exact signal that was
actually being modulated rather than the original version. The values can be guessed
by trial and error and I got it to a 1K resistor and a 220 pico farad capacitor. All I needed
to do was create this circuit and again run it through a logic analyzer and if I got the
modified Miller communication, which I did see as shown there, I would be able to work
with it.
circuit that was required and all that needed to happen was one of those pins would go to ground
and the other would go to an input pin which could then allow me to receive on a microcontroller
i decided to go for the 80 tiny 84 microcontroller because it's extremely simple extremely cheap
and it's quite easy to work with from a programming perspective it has eight kilobytes
of ram and 512 bytes of ram 8k of flash it can be programmed using an arduino or a dedicated
programmer and it can use excel crystals really well to do tuning to a correct frequency so i put
a 13.56 megahertz crystal there the dip package means it'd be really easy to build from a hobbyist
perspective it can be done on a breadboard or anything and it would be nice to it's very easy
to work with the gpios on it it does have good support for interrupts and timers which came to
be very important later but very bad support for the debugging also the 8-bit architecture on it
meant that it was very bad for debugging
doing encryption calculations
i added the 13.56 megahertz crystal which meant it ran in sync with the reader
i added the receiving circuit just to one pin which received the data and then tied another
pin to it to send data back using pulse with module modulation basically creating load on that
pin as it's receiving in order to get the data back due to uart on it which is the usual thing
you'd use for debugging on this particular platform not being feasible as the clock was
non-standard i basically dumped
out debug strings and debug data via software software-based
sbi just to another dev board so i could analyze the data i added an led which was attached to
confirm the device was working and i basically set up the state machine as you would see it
on a appropriate my fair classic tag so sending responses for selection and authentication when it
is meant to be done there are a few timing issues that came across the first thing i did when i was
running this was basically trying to receive data at a rate of 847 and a half kilohertz
now this should have allowed me to receive the modified miller data as it was going along
at predefined intervals but due to the fact that it had a huge amount of clock drift due to heat
time and power issues it meant that the thing would get out of sync very quickly and i'd only
receive about 50 of the transmissions instead what i did was basically check the difference
in time between each drop in the signal and use that to receive the data and that gave me a very
high accuracy enough to make the tag behave appropriately i then had to implement crypto 1 and
despite the fact that people don't want you to know about it.
The main library that's used is called Crapto1,
which is a great way of saying that it's a terrible encryption library,
and there's a huge amount of papers about how it works.
It's found to be based on 48-bit keys
that are basically split into two 24-bit keys
and just swapped between during authentication,
and due to the amount of bit shifts and calculations involved,
the 8-bit microcontroller will just have a few problems with it,
the main one being that bit shifts on the AVR microcontrollers,
the AT-Tinies, have to be done one at a time,
meaning if you want to do a 16-bit shift, that's 16 operations,
or sometimes if it's optimized, a lot quicker.
The main culprit for this issue was the filter function,
which is used to generate the encrypted bits as it went along.
This is the main filter function, and as you can see,
there's a lot of bit shifts, a lot of large numbers
that are larger than 8-bit, and lots of other calculations.
So we have these bit shifts,
which would need to be converted into much more efficient bit shifts,
we had these 20-bit values,
which are being calculated in C as 32-bit values,
but could be calculated as 20-bit if we did it in assembly,
and we had one 32-bit value, which had a few complications.
What I ended up doing was taking all the CryptoOne code
and converting it to AVR assembly in order to optimize it.
So I wrote from scratch all these filter functions and calculations
in order to find the efficiency where I could.
I used the SimAVR emulator because it's much easier to debug,
and put it right against the main CryptoOne,
and then I did a little authentication and basically did a unit test
to check that they were putting out the same data.
All the calculations could be sped up,
the most complex of which being the bit shifts,
which I could do by basically modifying how it performed those.
So if for 16-bit shifts, dropping the data down,
8-bit shifts, dropping it down slightly less,
4-bit shifts, swapping the upper and lower nibbles of the data,
and then just doing standard bit shifts when it was necessary.
This made the thing about 10 times faster,
meaning that it could now behave as a proper MyFair Classic tag with any reader.
This is the horrendous assembly that was used.
It's very quick, but not very well written.
And this is the final product.
Now, as you can see, it's a very, very simple circuit.
The lower one is everything you need to emulate a MyFair Classic tag on this platform,
and do it in raw in a way which will allow you to perform attacks on it,
or modify the authentication.
If we could play demo one now, that would be excellent.
Please.
I found that that reader that I was using, Afro Border from Taobao,
was also used in Beijing Airport, which was very exciting to take through customs.
But it did get through.
As said before, there were hardware limitations.
Due to the fact that it was 8K of flash and 512 bytes of RAM,
there wasn't enough room left to do anything more complex
with the authentication or encryption or assessment.
I couldn't add extra tooling to it, and just due to the fact that the hardware was not up to scratch,
I decided to make something a bit more complex in order to make a proper analysis tool.
Due to the fact that it had really slow responses, there were some readers which weren't compatible,
but I found that these readers often weren't compatible with Proxmarks or Chameleon minis either.
So I decided to build a bigger and better device using an STM32 microcontroller.
Now, these can be bought very cheaply in development boards,
have great support for debugging, and huge amounts of memory to work with.
The one I used was the STM32L496, which has one megabyte of flash and 320 kilobytes of RAM,
which is 640 times more than the ATtiny.
The clock speed could go up to 80 megahertz, but it could also tune to 72 megahertz,
which became very important later.
Also, the fact that it was using a 32-bit architecture and it was ARM
meant that encryption calculations were much, much easier to work with.
It also has a large number of useful peripherals, including USB and UART,
meaning it was easier to basically dump data out of it.
So it's not as complicated as it is going on.
I set it up using the STM32 cube, which is a very useful tool
that basically lets you use hardware extraction to set things up.
And then I could just copy a lot of the core code from the ATtiny version into it,
apart from the data for sending responses and receiving data from the reader.
There were going to be synchronization issues, though,
because it couldn't tune to the specific clock rate that it needed to, the 13.56 megahertz.
The internal clock of the chip is quite configurable
and can go from a huge number of frequencies,
due to the fact that the STM32 cube will take a value you give it
and work out exactly what it needs to do to get the clock that fast.
This could have caused problems with transmitting data but not receiving it,
because the spaces in time between each signal would still be fairly slow
and allow you to pick up the differences between them.
I didn't want to use an external crystal, because it would add complexity to the board,
and on a development board, this can also cause a few problems.
Without an accurate clock, though,
we could have a lot of problems with the clock,
and we couldn't do much work with it,
so I had to find a way to get in sync with it.
What I ended up doing was finding every frequency
that was within about 10% accuracy against 13.56 megahertz
in order to find one which could then be within range for the Manchester coding to still work.
I basically processed through these frequencies
and found that 72 megahertz was the fastest and most efficient frequency that could be used for this.
This is the same circuit as before, just built onto the development board.
It's got a big coil of wire, the tuned LC circuit,
and the envelope detector just attached to two pins and the ground.
That's all you need to emulate a MyFair Classic tag in hardware.
Because it was so efficient, so fast, and it had so much flash and RAM available,
I could implement a huge number of new features.
The first one I did was implement support for multiple tags.
This would mean if you had a reader that could support multiple tags,
you could make it pretend to be one, two, three, or more different kinds of tags.
These multiple requests can be used to cause exploits,
or just for making things more efficient when you're working with them.
All I needed to do was set up the same state machines over and over again,
and make it process through them as data was going through.
I could add dynamic key generation, so I could make the UIDs,
which are completely randomized on my device,
generate correct keys for the different readers.
So if you can generate a huge number of different UIDs,
you can get all the different keys that can be made using CryptoOne Attacks.
And then work with those to try and reverse-engineer how those keys are generated.
I started implementing DesFire.
Now, DesFire, the only place that I've seen it used is back in England,
where it's used for Oyster Cards in London.
It's an incredibly powerful protocol with very strong encryption,
but it's also not been implemented very often in other devices,
just because it is highly complex.
So what I ended up doing was taking my phone, which has a tool for doing my fare, DesFire,
and taped it to the tag that I had created.
And then went through the different communications,
sending responses appropriately as it went along.
And from there, I could build up to the point of doing authentication,
which works similarly to how it works in MyFair Classic,
but with much more robust and strong encryption.
There it is, just attached to the tag,
and that's all I needed to do to communicate with it.
So let's talk about some security weaknesses in NFC now,
now that we've built the appropriate tools for it.
So CryptoOne, as I've said before, is very, very weak.
So the attacks were shown in Dismantling MyFair Classic,
a very old paper which basically went through every single weakness possible
from the tag side, reader side, et cetera.
These included the fact that it uses a 48-bit key split into two,
which can then be processed separately.
Authentication is vulnerable to replay attacks
because of the weak random number generated on the tag.
The nonces can be used to recover a keystream,
which can then be used on brute-force attacks.
And it can be rolled back to the start of the authentication,
in order to get the report back.
original keys. So in order to do this, what you need to do is start authentication with
my tag or any other one or a proxmark until the point where the reader has sent back the
8-bit response from the original nonce. This response contains the random values and the
ones generated from the tag. And this can be used to be XORed with the original nonce
because it's a deterministic value in order to generate 32 bits of keystream. Basically
then, you can separate those two 32 bits of keystream into 16 bits of keystream, which
can then be handled separately. So what you would do is take one of the keys and process
through 16 of those bits and find every single value out of the 24 bits that matches that
keystream and then do it for the other 16 bits as well. This in one way, so going from
the first bit of the keystream to the end, this would create 200,000 values from the
original 16 million. If you did it backwards, you'd get 30,000 different keys from the
original for both the 24 bits of encryption, which can then be used to work together.
These matching key pairs then can be processed together just via brute force very quickly
and you can end up cracking the keys in about 10 minutes with this process. So that's the
authentication request. That's the nonce response from the tag. That's the random value
and that is the encrypted value generated from that original value. This can be used
to perform offline cracking. You just need two reads from a tag and nothing else.
And it can be used much more efficiently than reader-based attacks when it comes to
a tag. So rather than trying to pickpocket someone to do attacks on the tag, you can
just walk up to the reader and do it. And because it's using offline cracking, you just
go home and wait for the keys to be cracked. This functionality is available on other devices,
but it's never used because it's very, very inefficient to work with. It's just not very
practical.
So I decided to implement this attack taking a Japanese video game, which has a USB reader
on it and basically has no research whatsoever so far. So I wouldn't be able to just guess
the keys in order to perform this attack. I'd have to use this process in order to authenticate
with them.
So I worked out the USB protocol just by using a BeagleBone Black and the USB proxy tool
to man in the middle of the communication and then made it just dump the tag UIDs and
request data, which would then create authentication. The reader was found to be compatible with
the Proxmark. It wasn't found to be compatible with the Proxmark just because the speed of
the response is expected.
So I'd say from the reader to the tag and the amount that's going on on that device.
So there's the tag. Just attach the reader and if we could do demo number two now, please.
So we just placed it on the reader and it just generates these authentication tokens.
And that's the UID and it's just sending authentication data, which can then be processed
later.
I basically dumped these out.
So via UART on the device and then put it through a program on my laptop, which just ran through the keys and generated the keys from them.
And as you can see, it was done in 10 minutes.
And this was very consistent as I processed through different types of keys and different UIDs.
Some of the improvements that could be made to CryptoOne is first, we increased the key size to something much larger.
This would have some problems with, obviously, efficiency when it came to the tags, because there's not a lot of complex circuitry in there for doing encryption.
But it would have made it more secure.
Even up to 64 bits would have made it a huge amount more secure.
The usage of a single large key that was processed through would be much better than just having two keys that are processed together, because there wouldn't be that separation that could be used for the attack.
And an improved random number generator would be just so much better for this.
And as this weakness was because of known plaintext.
Because of tags, it was just much better.
So let's talk about some raw protocol weaknesses.
Now, this is very important, because most other attack tools, aside from the more complex ones, the more expensive ones, like the Proxmark, the Chameleon Mini, et cetera, require complex NFC-based chipsets.
Which means it can't go down to the raw communication level in order to perform attacks.
This means that these tags, usually, you feed it a UID, and it handles all the communication for you, apart from some of the authentication.
As I could change any part of the communication by doing this raw communication, I could do anything I wanted to it.
The greatest weakness I found was denial of service using the anti-collision procedures which happened at the initial enumeration.
So here's a quote from the Texas Instruments documentation on this.
So, due to the recursive nature of the anti-collision algorithm, there is a risk of a stack overflow.
I found this to be very true in a huge number of readers.
And what people generally do is just never implement this anti-collision feature because of it.
But when do they do it? They often get it wrong.
So, every time the reader sent a request to my tag, I would send completely messy responses back that looked like there were two tags on the reader sending a response.
I constantly did this, despite it trying to request more and more bits.
And the tag never limited how much data was being sent back.
So the reader would then basically constantly try and find the unique UID.
Even past the maximum size of UID.
And this is a very common feature that can be found in the reader.
This weakness is known about, but it's really not found anywhere because no one really implements this feature.
But it can be used to crash readers when you use it.
There's a few high-level protocol weaknesses.
For instance, each tag type uses things called NDEF data or block data, etc., which has different sizes and different methods for communicating.
And each of these have weaknesses in the buffers and size just from how they work.
The authentication mechanism.
Often have weaknesses, as demonstrated before, in the My Fair Classic tag.
But it's extremely easy to identify them in other things as well.
Weaknesses in things like the My Fair Ultralight, where it just sends a plain text key, is obviously very simple to sniff.
The reason that Deathfire, etc., is much more secure is because it's using authentication, which just doesn't have these weaknesses in it.
I decided to compile all this research up into one tool for testing.
Proper testing purposes.
I decided to take everything that I'd learned, everything I'd built, and put it inside a toy sonic screwdriver.
And basically take all the tools and the exploits and put them one by one in a device so I can click through them at will in order to do different attacks.
The first one would be fuzzing.
Second, it transmits the authentication data via RF.
Yeah, can we play demonstration in video three?
So what that was doing is basically randomizing its unique identifiers.
And as it was processing through them, essentially sending that data via RF to my computer via an RTL-SDR.
So what it basically has is an ASK transmitter, as shown in the pictures.
It's what you generally use for opening a garage door, but it's very useful for communicating small amounts of data in a project.
And I could then use that to crack that data offline remotely.
Can we play demonstration four just to demonstrate that, please?
So yeah, literally just sending data to my computer via the RTL-SDR again, which is very simple.
This tool came to be very useful, and I'm still adding features to it.
But I think after a while, it'll be quite useful.
I think I'm going to put it in a different case, but I definitely think it's got some merit.
So what I'm going to be doing now is basically releasing all the source code, all the designs and everything,
so you can look through them and see what you want about them.
The most important of these would be the STM32 tools, which have the most credibility for future work,
as it's very powerful and can be used for a lot of different things.
I'm going to set up the boards to be a bit more complex and a little bit more tolerant of errors and that sort of thing.
And I'm going to start implementing DESFire properly.
So if we can implement this entire protocol and feature, then the weaknesses can be identified in it much better.
And we'll be able to find exploits and weaknesses in the encryption, which can then be further used in order to perform attacks on it.
There's my GitHub if you want to go look for the code.
And thank you very much.
Thank you very much.
